In data communication environments, many different vendors provide a number of products for specific services. A machine, an application operating on a machine, and a software module or a file system residing on a machine (“component”) developed by one vendor might have difficulty communicating with a component developed by another. Domain-specific protocols have been developed to partially deal with this difficulty by enabling components to communicate with each other using a common language. But since new components are constantly being introduced into and taken out of an environment it has been difficult to develop a system or protocol that is not domain-specific yet is sufficiently robust to enable unknown, arbitrary components to enter the environment and communicate with each other without having to be programmed explicitly in advance.
Further, some components might be aggregate components, which represent “collection-like” entities. These might be co-located on the same machine as other components, or accessed remotely over a network. Further, the aggregate components might include a number of entities, such as fileservers, nameservers, network bridges and gateways, and software modules that perform new discovery protocols, which may logically “contain” files, names, and the hosts and components accessible via the new network or protocol, respectively. But in order to use these entities, developers must have specific prior knowledge about the programmatic interfaces for these entities. When a new type of collection-like or aggregate component is introduced, the other components must be reprogrammed to allow them to access the new collection and the entities contained within it. Thus, components that desire taking advantage of multiple protocols, networks, services, search mechanisms, file servers, and other entities that provide such “collection-like” behavior, must be created with knowledge of each and cannot incorporate new technologies without expensive reprogramming and labor-intensive manual upgrades.